<?xml version="1.0" encoding="iso-8859-1"?>
<?xml-stylesheet type="text/css" href="chapter.css"?><chapter>
  <title>Chapter 3:	First Schema</title>
  <simplesect/>
  <sect1>
    <title>Getting started</title>
    <para>Throughout the book, we will be using variations of the same document describing a library:</para>
    <programlisting>
<![CDATA[ <?xml version="1.0"?>
 <library>
  <book id="b0836217462" available="true">
   <isbn>0836217462</isbn>
   <title xml:lang="en">Being a Dog Is a Full-Time Job</title>
   <author id="CMS">
    <name>Charles M Schulz</name>
    <born>1922-11-26</born>
    <died>2000-02-12</died>
   </author>
   <character id="PP">
    <name>Peppermint Patty</name>
    <born>1966-08-22</born>
    <qualification>bold, brash and tomboyish</qualification>
    </character>
   <character id="Snoopy">
    <name>Snoopy</name>
    <born>1950-10-04</born>
    <qualification>extroverted beagle</qualification>
   </character>
   <character id="Schroeder">
    <name>Schroeder</name>
    <born>1951-05-30</born>
    <qualification>brought classical music to the Peanuts strip</qualification>
   </character>zeroOrMore
   <character id="Lucy">
    <name>Lucy</name>
    <born>1952-03-03</born>
    <qualification>bossy, crabby and selfish</qualification>
   </character>
  </book>
 </library>]]>
    </programlisting>
  </sect1>
  <sect1>
    <title>Our first patterns</title>
    <para>In plain English, we could describe this document as being:</para>
    <itemizedlist>
        <listitem><para> a <literal>library</literal> element composed of one of more</para></listitem>
        
          <listitem><para> <literal>book</literal> elements having</para></listitem>
          
            <listitem><para> <literal>id</literal> and <literal>available</literal> attributes and</para></listitem>
            <listitem><para> an <literal>isbn</literal> element composed of text</para></listitem>
            <listitem><para> a <literal>title</literal> element with a xml:lang attribute and a text node</para></listitem>
            <listitem><para> one or more <literal>author</literal> elements with</para></listitem>
            
              <listitem><para> an <literal>id</literal> attribute</para></listitem>
              <listitem><para> a <literal>name</literal> element</para></listitem>
              <listitem><para> an optional <literal>born</literal> element</para></listitem>
              <listitem><para> an optional <literal>died</literal> element</para></listitem>
            
            <listitem><para> zero or more <literal>character</literal> elements with</para></listitem>
            
              <listitem><para> an <literal>id</literal> attribute</para></listitem>
              <listitem><para> a <literal>name</literal> element</para></listitem>
              <listitem><para> an optional <literal>born</literal> element</para></listitem>
              <listitem><para> a <literal>qualification</literal> element.</para></listitem>
            
          
        
      </itemizedlist>
    <para>The good news -and what makes Relax NG so easy to learn- is that in its simplest flavor,it's pretty much a XML formalization of this statement with simple matching rules:</para>
    <itemizedlist>
        <listitem><para> &quot;library element&quot; translates into &lt;element name=<literal>library</literal>&gt;...&lt;/element&gt;</para></listitem>
        <listitem><para> &quot;id attribute&quot; translates into &quot;&lt;attribute name=&quot;id&quot;/&gt;</para></listitem>
        <listitem><para> &quot;one or more&quot; becomes: &lt;oneOrMore&gt;...&lt;/oneOrMore&gt;</para></listitem>
        <listitem><para> &quot;zero or more&quot; becomes: &lt;zeroOrMore&gt;...&lt;/zeroOrMore&gt;</para></listitem>
        <listitem><para> <literal>text</literal> is: &lt;text/&gt;</para></listitem>
        <listitem><para> <literal>optional</literal> is: &lt;optional&gt;...&lt;/optional&gt;</para></listitem>
      </itemizedlist>
    <para>We've seen in &quot;Chapter 2: Simple Is Beautiful&quot; that almost everything is a pattern for Relax NG and each of these Relax NG elements are patterns. Let's now spend some time to introduce each of them.</para>
    <sect2>
      <title>&lt;text/&gt;</title>
      <para>This pattern is the simplest we can think of and simply matches a text node. More exactly, it matches zero or text nodes and we'll see in &quot;Chapter 6: More Patterns&quot; that the <literal>text</literal> it makes a difference in the context of mixed content models (i.e. to define elements which may have both sub elements and text nodes) but until then we can think of it as matching a text node.</para>
      <para>By extension the <literal>text</literal> pattern also matches any attribute value even if attribute values are not considered as nodes by the XML infoset.</para>
      <para>The XML expression for <literal>text</literal> patterns is just:</para>
      <programlisting>
<![CDATA[ <text/>]]>
      </programlisting>
    </sect2>
    <sect2>
      <title>&lt;attribute/&gt;</title>
      <para>As expected, the <literal>attribute</literal> pattern matches attributes. The name of these attributes are defined in the <literal>name</literal> attribute of the <literal>attribute</literal> pattern and the content of these attributes is defined as a child element of the <literal>attribute</literal> pattern (don't worry, that's easier to write and read than to explain!).</para>
      <para>To define the <literal>id</literal> attribute, we could thus write:</para>
      <programlisting>
<![CDATA[ <attribute name="id">
  <text/>
 </attribute>]]>
      </programlisting>
      <para>This would read as: &quot;an attribute named id with a text value&quot;. Since any attribute can have a value and that the <literal>text</literal> pattern isn't restrictive in this case, it has been made optional and this definition is strictly equivalent to the following one:</para>
      <programlisting>
<![CDATA[  <attribute name="id"/>]]>
      </programlisting>
      <para>The last thing we need to mention about this pattern is that even if in most of the cases the name of the attributes are defined by the <literal>name</literal> attribute or the <literal>attribute</literal> pattern, it is also possible to define sets of possible names for an attribute. This feature will be explained in detail in &quot;Chapter 12: Writing Extensible Schemas&quot;.</para>
    </sect2>
    <sect2>
      <title>&lt;element/&gt;</title>
      <para>Just as the <literal>attribute</literal> pattern matches attributes, the <literal>element</literal> pattern matches elements. To define the <literal>name</literal> element, we will write:</para>
      <programlisting>
<![CDATA[ <element name="name">
  <text/>
 </element>]]>
      </programlisting>
      <para>As mentioned for the <literal>attribute</literal> pattern, it is also possible to replace the <literal>name</literal> attribute of the <literal>element</literal> patter by a set of names as explained in detail in &quot;Chapter 12: Writing Extensible Schemas&quot;.</para>
      <para>Not all elements accept text nodes and for that reason, the <literal>text</literal> pattern isn't implicit within elements. In fact there is no implicit content for elements and the content of each element must be explicitly described even when the element is always empty.</para>
      <para>The fact that a <literal>text</literal> pattern matches zero or more text nodes means that this definition of the <literal>name</literal> element would match empty elements such as:</para>
      <programlisting>
<![CDATA[ <name/>]]>
      </programlisting>
      <para>as well as more traditional names such as:</para>
      <programlisting>
<![CDATA[ <name>Charles M Schulz</name>]]>
      </programlisting>
      <para>We will see in &quot;Chapter 7: Constraining Text Values&quot; how we can add additional restrictions to text nodes to avoid empty elements and in &quot;Chapter 8: Datatype Libraries&quot; how to use the datatypes from W3C XML Schema to add more specific restrictions such as being a valid date.</para>
      <para>Attributes can be added within elements and to define the <literal>title</literal> element we will write:</para>
      <programlisting>
<![CDATA[ <element name="title">
  <attribute name="xml:lang"/>
  <text/>
 </element>]]>
      </programlisting>
      <para>We will see the support of namespaces in &quot;Chapter 11: Namespaces&quot; but we can already note how straightforward it is. Here we had to define an attribute (xml:lang) from the XML namespace and we've just added the description of this attribute straight away in out schema. In the case of the XML namespace which is considered as predeclared in any XML document conform to the Namespaces in XML recommendation and implicitly assign the &quot;xml:&quot; prefix to &quot;http://www.w3.org/XML/1998/namespace&quot;, we do not need to declare the namespace. In the general case, we would have needed to declare the namespaces using mechanisms described in &quot;Chapter 11: Namespaces&quot;.</para>
      <para>Note that Relax NG is clever enough to know that attributes are always located in the start tag of XML elements and that their order is not considered as significant. This means that the <literal>attribute</literal> pattern may be located anywhere in the definition of elements and that it would have made no difference if we had written:</para>
      <programlisting>
<![CDATA[ <element name="title">
  <text/>
  <attribute name="xml:lang"/>
 </element>]]>
      </programlisting>
      <para>In addition to text nodes and attributes, elements can also include sub elements and we could define the <literal>author</literal> element as:</para>
      <programlisting>
<![CDATA[ <element name="author">
  <attribute name="id"/>
  <element name="name">
   <text/>
  </element>
  <element name="born">
   <text/>
  </element>
  <element name="died">
   <text/>
  </element>
 </element>]]>
      </programlisting>
      <para>That's not exactly what we want, though since the <literal>born</literal> and <literal>died</literal> elements should have been made optional. To do so, we need to introduce a new pattern:</para>
    </sect2>
    <sect2>
      <title>&lt;optional/&gt;</title>
      <para>The <literal>optional</literal> pattern just makes its content optional. To specify that the <literal>born</literal> and <literal>died</literal> elements are optional, we will write:</para>
      <programlisting>
<![CDATA[ <optional>
  <element name="born">
   <text/>
  </element>
 </optional>
 <optional>
  <element name="died">
   <text/>
  </element>
 </optional>]]>
      </programlisting>
      <para>Note that this is different from</para>
      <programlisting>
<![CDATA[ <optional>
  <element name="born">
   <text/>
  </element>
  <element name="died">
   <text/>
  </element>
 </optional>]]>
      </programlisting>
      <para>And also different from</para>
      <programlisting>
<![CDATA[ <optional>
  <element name="born">
   <text/>
  </element>
  <optional>
   <element name="died">
    <text/>
   </element>
  </optional>
 </optional>]]>
      </programlisting>
      <para>In the first case, each element is embedded in its own <literal>optional</literal> pattern. The two elements are thus independently optional and I can include both of them, none of them or one of them in valid instance documents. In the second case, both elements are embedded in the same <literal>optional</literal> pattern and we can only include either none of them or both of them in instance documents. In the third case, a first optional pattern includes the <literal>born</literal> element and an optional <literal>died</literal> element meaning that we can find either both of them or none of them in an instance document or the <literal>born</literal> element only but that we forbid the <literal>died</literal> element if the <literal>born</literal> element isn't there.</para>
      <para>None of the combinations is &quot;right&quot; or &quot;wrong&quot;, they are just different pattern combinations allowing different element combinations in the instance documents and corresponding to different use cases. What's nice with Relax NG is that there are so few restrictions that almost any combination to which you can think of is allowed. To be honest I must admit that there are some few restrictions and they will be covered in &quot;Chapter 15: Simplification And Restrictions&quot;.</para>
    </sect2>
    <sect2>
      <title>&lt;oneOrMore/&gt;</title>
      <para>The <literal>oneOrMore</literal> pattern specifies that its content may appear one or more time. The use case for this pattern in our example is to define that a book must have one or mote authors:</para>
      <programlisting>
<![CDATA[    <oneOrMore>
     <element name="author">
      <attribute name="id"/>
      <element name="name">
       <text/>
      </element>
      <element name="born">
       <text/>
      </element>
      <optional>
       <element name="died">
        <text/>
       </element>
      </optional>
     </element>
    </oneOrMore>]]>
      </programlisting>
    </sect2>
    <sect2>
      <title>&lt;zeroOrMore/&gt;</title>
      <para>The last pattern needed in our example is <literal>zeroOrMore</literal> and you'll have guessed that it tells that its content may appear zero or more time like for our <literal>character</literal> elements:</para>
      <programlisting>
<![CDATA[    <zeroOrMore>
     <element name="character">
      <attribute name="id"/>
      <element name="name">
       <text/>
      </element>
      <optional>
       <element name="born">
        <text/>
       </element>
      </optional>
      <element name="qualification">
       <text/>
      </element>
     </element>
    </zeroOrMore>]]>
      </programlisting>
    </sect2>
  </sect1>
  <sect1>
    <title>Complete schema</title>
    <para>We have now in hand all the patterns needed to write a full schema expressing all we've said for this example:</para>
    <programlisting>
<![CDATA[ <?xml version = '1.0' encoding = 'utf-8' ?>
 <element xmlns="http://relaxng.org/ns/structure/1.0" name="library">
  <oneOrMore>
   <element name="book">
    <attribute name="id"/>
    <attribute name="available"/>
    <element name="isbn">
     <text/>
    </element>
    <element name="title">
     <attribute name="xml:lang"/>
     <text/>
    </element>
    <oneOrMore>
     <element name="author">
      <attribute name="id"/>
      <element name="name">
       <text/>
      </element>
      <optional>
       <element name="born">
        <text/>
       </element>
      </optional>
      <optional>
       <element name="died">
        <text/>
       </element>
      </optional>
     </element>
    </oneOrMore>
    <zeroOrMore>
     <element name="character">
      <attribute name="id"/>
      <element name="name">
       <text/>
      </element>
      <optional>
       <element name="born">
        <text/>
       </element>
      </optional>
      <element name="qualification">
       <text/>
      </element>
     </element>
    </zeroOrMore>
   </element>
  </oneOrMore>
 </element>]]>
    </programlisting>
    <sect2>
      <title>Constraining number of occurrences</title>
      <para>Those of you familiar with W3C XML Schema will probably have noted that the control over the number of occurrences is specified ala DTD and doesn't have the fine granularity of W3C XML Schema's minOccurs and maxOccurs. Relax NG has been designed in this way because these four cases (exactly once which is the default, optional, zero or more and one or more) are the most common and also because if applications need a finer granularity, they can create it using these four basic occurrence constraints. If for instance, we needed to define that each book's description should include between two and six characters, we could write it as two mandatory characters followed by four optional ones and write:</para>
      <programlisting>
<![CDATA[    <!-- 1 -->
    <element name="character">
     <attribute name="id"/>
     <element name="name">
      <text/>
     </element>
     <optional>
      <element name="born">
       <text/>
      </element>
     </optional>
     <element name="qualification">
      <text/>
     </element>
    </element>
    <!-- 2 -->
    <element name="character">
      .../...
    </element>
    <!-- 3 -->
    <optional>
     <element name="character">
     .../...
      </element>
     </element>
    </optional>
    <!-- 4 -->
    <optional>
     <element name="character">
     .../...
     </element>
    </optional>
    <!-- 5 -->
    <optional>
     <element name="character">
     .../...
     </element>
    </optional>
    <!-- 6 -->
    <optional>
     <element name="character">
     .../...
     </element>
    </optional>]]>
      </programlisting>
      <para>This is certainly verbose but we will see how we can define and reuse patterns to reduce the verbosity.</para>
    </sect2>
    <sect2><title>Russian doll schemas</title><para>Let's look side by side at the schema and the instance document:</para>
        <figure id="_russian-doll"><title>russian-doll</title><graphic fileref="russian-doll.png"/></figure>
      <para>We see that even though information have been added in the schema to describe the content of the text nodes and the number of occurrences, the schema keeps the same hierarchical structure than the instance document.</para><para>This type of schema in which the different definitions are embedded in each other (the definition of the <literal>library</literal> element physically contains the definition of the &quot;author element&quot; which physically contains the definition of the <literal>name</literal> element) are often called &quot;Russian doll schemas&quot;. We will see in &quot; Chapter 5: Flattening Our First Schema&quot; how Russian doll schemas may be broken into independent patterns combined together to reproduce the structure of the instance document. Before this, we'll have a look in nxet chapter, &quot;Chapter 4: Non XML Syntax&quot; to an alternative, equivalent, compact and non XML syntax for Relax NG.</para></sect2>
  </sect1>
</chapter>
